\chapter{Future Work}
\label{ch6}
The more we work on our application, the better we make it. That's something that can probably be said for all projects. While all the requirements that were set for iSquirrel have been met, there are still some issues that we can improve. Performance, for example, is something that can never reach its optimum. So far, we are satisfied with iSquirrel's speed. The methodology, however, that our application uses could have been different, or even better, it could have had more dimensions. 

Two main aspects that we can improve, in the future, are our \emph{recommenders} and our \emph{social network}. Since iSquirrel is a community-based recommender system, these two parts of our project are naturally the first to be extended. Also, a further improvement, which was the source of much debate in our team meetings, is to offer the ability to delete an interest from your profile.

Apart from improving the existing system, we could provide additional features that would encourage users to use iSquirrel, such as \emph{RSS Feeds}, \emph{Email Alerts} and the ability to export their \emph{``liked"} pages as browser bookmarks. This would increase compatibility with existing web technologies and would increase users' trust of our system.

\section{Deleting interests}

Many of our users pointed out that we omitted to include a delete or at least a modify button for their interests. While this might seem like a naive move on our behalf, with greater analysis one will see that such a feature comes with a great deal of complexity. 

As mentioned in previous sections, when a user adds an interest, their static profile is expanded to include that interest and static recommendations are generated for it and get stored in the database. Furthermore, when a user \textit{``likes''} a recommendation, their dynamic profile builds up by adding new properties to it and, in a way, the system learns what the user likes. So, deleting an interest would mean deleting both static and dynamic recommendations, properties from the user's dynamic profile and the interest in question from the static profile. 

The way our database is set up, does not allow the system to determine the origin of each recommendation (i.e the interest it comes from) making it impossible to know which interest to save with each \emph{``like"}, each property in the dynamic profile and each dynamic recommendation. Therefore, deleting an interest is impossible since we do not know what to delete to completely remove any trace of that interest from the user's profile.

This problem can be solved and a delete/modify button can be included in future releases, by adding extra information about each recommendation in the database. When a recommendation is chosen to get displayed, we can make note the interest it comes from, thus any new properties and dynamic recommendations generated, would get stamped with the noted interest and written to the database. A deletion would then be trivial. It would include a search and delete of all static and dynamic recommendations as well as all properties in the dynamic profile stamped with that interest.

\section{Improving our recommenders}

\subsection{Multi-dimensional static recommender}
Static recommendations are generated based on the interests that a user enters in our system. We extract the \emph{subject} of these interests, we also find the subjects that are one level more specific and store all the subjects in the static profile of the user. Static recommendations are then generated by finding articles that belong to the subjects we have stored in the static profile of the user.

One level more specific subjects are not the only way to go. If these subjects are the \emph{children} of the main subject the user is interested in, why not generate recommendations based on the \emph{parents}? Or recommendations based on the \emph{siblings} of the main subject of interest?

\subsubsection{Relevance of the new recommendations}
First of all we want to make clear that the main subject(s) of an interest will always be included in the process of generating static recommendations. However, this can be very limiting therefore we do need to have a way for increasing the breadth of the subjects we consider and of the recommendations we produce.

If we provided recommendations based on sibling subjects, or parent subjects, would they be relevant to the interests of the user? Answering such a question is difficult, as the answer could be different depending on the case. In most cases the results would be relevant. In the case of parent subjects they would be a bit more general, and in the case of sibling subjects they would be more specific to a sibling subject, that is still very closely related to the original subject. Right now the results are not too general, and not too specific. However we would like our users to have the option to choose how they like them.

We can also make the following observation: The hierarchy of subjects is \emph{pyramidal}. That means that one should expect, for a given interest - subject, to have more children that parents. In the case of siblings it would depend on the level of the tree one is currently at. In our implementation the difference between the number of children and parents is reflected by storing more subjects for each interest of the user, hence more recommendations without sacrificing their quality.

If we were only going to consider the parents of a subject, then it would have been very limiting, given that most subjects usually have one to five parents. If each subject could bring twenty recommendations then for one interest we would have to choose between eighty recommendations (20 from the immediate subject + 3x20 from four parents). Using the ``children" approach the recommendations would probably be four times more, if the same subject had twelve children. In the case of siblings, things would depend on the level of the tree we are looking at. For example a level at the beginning of the hierarchy would normally generate around three extra subjects. One closer to the end of the pyramid could potentially generate twenty extra siblings or even more, giving around five hundred recommendations to choose from. 

\subsection{Using resources not semantically annotated}
Another idea that would expand the scope of our project is allowing our users to like not only semantically annotated pages e.g. Wikipedia articles, but also any other pages on the Internet. Something like that would have the benefit of a much bigger sample of  \emph{``liked"} pages for each user, as they would be able to use iSquirrel whenever they are online, not only when they are reading an article on Wikipedia.

On top of that, the recommendations could also be about those pages. One way of recommending pages that don't have anything to do with DBpedia, is by checking how close two users are. We can already decide how close two users are, using the same algorithm we use when suggesting friends in Section~\ref{sec:community}. For those users that we believe are close enough, we could recommend the pages that the other user has liked; recommendations outside of Wikipedia, that are perfectly justified.

Something like that would be trivial. The difficult part comes down to getting knowledge about a user, or even adding to their \emph{Dynamic profile} based on non-semantically annotated web pages they have liked.

\subsubsection{Scraping web pages}
Following a path like that would require the use of parsers for the generation of RDF (Resource Description Framework) data. For each page that a user \emph{``likes"}, we would have to scrap its contents, and classify it using a more formal specification. In our case the outcome of an operation like that would be semantic ontologies. Piggy Bank\footnote{Piggy Bank's website: \url{http://simile.mit.edu/wiki/Piggy_Bank}} is an example of such an application.

If we were successful at generating semantic ontologies from \emph{``liked"} pages, then we could modify the dynamic profile of the user accordingly. It wouldn't matter if \emph{properties} in the dynamic profile come from Wikipedia articles or from any other resource on the Internet. All that should matter is that those properties describe the character of a user, and should all be taken into consideration when generating recommendations.

\subsection{Classification of information} 
Something that would make iSquirrel stand out is an automated way for classifying the information in the profiles of our users. The benefits should be apparent: more specific recommendations for books, music, films etc. To illustrate this point, let us show an example. Imagine you want to have a special section in the website for recommending books. How would that be implemented? If the dynamic profile was divided into sections, then under the category ``books" we could quickly identify the favourite author of the user ( or genre, size of book etc ) and provide immediately the right recommendations.

Right now we are not able to provide specific recommendations about a subject, because the profile of a user is not divided into sections. The dynamic profile of a user is a chaotic pool of information. While it is true that we can query a profile and find out which author appears more frequently, something like that would be troublesome and messy, as we would have to find out how an ``author" is represented in the profile and then create a query on the fly to retrieve the information we want. 

The idea here, to avoid opportunistic needs for queries like that, is that we create an API that would be used to identify the category a piece of information should belong to, and before entering the dynamic profile of the user, it would get tagged with its category. We would then have a structured image about the personality of the user.

On a higher level life would be so easy. We could run commands that show, for example, which users like thriller books. It would be done in such a way that no specific information about how this genre is represented would be used. The details of the implementation would be well hidden.

Another great benefit of an approach like that is the fact that we could use other resources apart from Wikipedia, when \emph{``liking"} something. Take for example a user who listens to a song on YouTube. If that user used iSquirrel to show that they like the song, then we could store the information about that song under the music category, and then use it to generate even more recommendations. That is, Wikipedia would no longer be the primary resource for information gathering on every topic.

\subsubsection{Complexity}
An approach like that would appear very difficult to implement. We would first have to decide what categories to include in the project. We would then have to do research and find out how they are semantically represented, and then write code that classifies resources in the right categories. A lot of parsing would be involved when classifying information.

The big issues here are that there a lot of categories to consider - think for example about books; there are science fiction books, romance, drama etc. Parsing of the resources we get could also appear problematic: when a user likes a YouTube video do they like it because of the song on the background, or do they actually like its video-clip? And finally, how do we modify our existing databases and how do we ensure backwards compatibility at the time of introduction of the new method? All of these questions should be considered extensively before proceeding with the implementation of this idea.

\section{Building a better social network}
\subsection{Interaction with friends}
Users of iSquirrel can, right now, have friends, view their interests and also see what pages they like. However, conventional features that other community-based applications offer such as emailing friends, instant messaging and a feedback area are not supported.

Allowing users to email each other would be easy in terms of implementation. We would have to create another table in our database, with columns describing the sender and receiver of the message, and details about the message - including whether it was read by the user. Whenever a user logins in our system we would check this table for new emails for the user, and if there are any then we would simply inform the user about the new message.

If more real-time communication is preferred, then instant messaging is the answer. A solution could either involve the use of AJAX requests, or, more appropriately, setting up an IM server and using a platform such as Jabber\footnote{Jabber's website: \href{www.jabber.com}{www.jabber.com}} to implement the messenger.

A feedback area would be a good idea. Feedback can be given from users, to other users, about pages they have liked. We can set up a public ``liked pages" section for each user, and other members of iSquirrel can see it and leave their comments. Every time a user \emph{``likes"} a page we can mark this as an activity, and other users will be able to comment on someone's activity.  We can also have the option for users to keep this section private.

One of the questions we should answer before proceeding with the suggestions above is how much emphasis do we want to put on the ``community part" of iSquirrel. If too much attention is paid to it, will iSquirrel lose from its ``recommender" side? Or will changes merely improve iSquirrel's popularity and make it easier for marketing? Clearly, the changes should occur gradually so that any possible risks for losing credibility are reduced.

\subsection{Private accounts}
Finally, we could have different modes of confidentiality for our user. Right now everybody can see someone else's interests, simply by searching with their names. This can be considered undesired by many, so we could provide the option for a private account. Private accounts could also appear useful when someone doesn't wish to be added as a friend. Adding a friend, right now, is done without asking for the permission of the other user. 

What about the recommendations based on ``what your friends like"?  If someone decides that they don't want to benefit from the community, they should be aware that they are limiting themselves and they can not take full advantage of iSquirrel. The only recommendations they would receive are those based on their interests, from the static and dynamic recommenders.

\section{RSS feeds \& email alerts}

Some of the users expressed their concern that they already have too many accounts online. That means, that they wouldn't want to keep on visiting our website to get their recommendations. They prefer having everything in one place.

To fulfill this need we could provide them with RSS Feeds. RSS is a standardised format that follows the specification described in \cite{RSSSpec} and can be used to provide summary information for blog entries, news articles, videos and music. Each user would then have his own private RSS Feed with DBpedia articles, Video \& Music Recommendations. The user would be able to choose how often they wants their feeds to be updated and what kind of recommendations (articles, video or music) they wants. We could even provide them with multiple feeds, for example a feed for a specific interest.

Email Alerts would work in a similar way. The system can be sending an email every day or every week with the most relevant recommendations.

\section{Exporting bookmarks}

The more experienced users of the web prefer using services that are compatible with the standards and allow them to freely move their data to another service. By providing the feature of exporting the \emph{``liked"} pages into bookmarks for Safari, Firefox, Internet Explorer etc., would encourage this group of users to use our service.

This feature would allow existing users to export some of the recommended pages and add them to their browser's bookmarks menu for quicker access.
